feat(cloud-registry): verifications - #578

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="301" />
<code_context>
+        this.own = { id, verification, provider };
+      }
+    }
+    this.changed(id, verification);
+  }
+
</code_context>
<issue_to_address>
**Old registry results corrupt new registry state**

When a mutation is pending while the app switches registries with an overlapping service ID, and the old response arrives afterward, `changed()` emits only the service ID and verification, so a list handler cannot distinguish the old registry’s result from the new registry’s. It can store or delete verification state in the new registry’s map, leaving the list with incorrect verification state.

Include registry identity in the event detail and have list handlers apply results only to the matching registry.

Also at `packages/ecc-client-elixir-cloud-registry/src/events/ecc-service-verification-changed.ts:5-7`, `packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts:386`.
</issue_to_address>

### Comment 2
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="224-229" />
<code_context>
+    this.loadRequest += 1;
+    const request = this.loadRequest;
+    const id = this.targetId;
+    if (this.verification !== undefined) {
+      const { own } = this;
+      this.current =
+        own && this.showsSame(own.id, own.provider)
+          ? own.verification
+          : this.verification;
+      return;
+    }
</code_context>
<issue_to_address>
**Old registry badge appears on new registry**

When the provider changes to a different registry while `verification` still contains a value loaded from the previous registry, `load()` treats any defined `verification` as authoritative without associating it with a registry. If the provider switches from registry A to registry B before the app replaces that property, the component skips B's GET and shows A's matching verification as B's, so users see a false Verified badge.

Scope supplied verifications to their registry and discard or reload them when the component switches to a different registry.
</issue_to_address>

### Comment 3
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="186" />
<code_context>
+      changedProperties.has("baseUrl") ||
+      changedProperties.has("serviceId") ||
+      changedProperties.has("verification") ||
+      (changedProperties.has("service") && previous?.id !== this.service?.id)
+    ) {
+      this.load();
</code_context>
<issue_to_address>
**Stale verification reappears as verified**

When the service’s URL or API type changes and later returns to its previously verified values without changing its ID, `updated()` skips `load()` when the service changes but keeps the same ID, leaving `current` unchanged. When the service returns to its old values, `matchesVerification()` matches that stale result and the component shows “Verified” even though the registry removed the verification.

Reload or clear `current` whenever the service changes, including changes to its URL or API type.

Also at `packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts:227-229`.
</issue_to_address>

### Comment 4
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="340" />
<code_context>
+      this.applied(id, verification, provider);
+    } catch (err) {
+      this.setPending(id, false);
+      this.fail(failureDetail(id, "verify", err, "Failed to verify service"));
+      if (
+        statusOf(err) === 409 &&
</code_context>
<issue_to_address>
**Mutation failures leave stale state**

When a verify or remove is applied by the registry but the client receives a timeout, connection failure, or error response, `verifyService()` and `removeVerification()` treat every non-conflict/non-404 rejection as a failed mutation without reconciling state. If the registry applied the change but the response was lost or errored, the component and any event-driven app map keep showing the old verification state.

Reconcile the verification after ambiguous mutation failures, while still reporting the failed request.

Also at `packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts:373`.
</issue_to_address>

### Comment 5
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="301" />
<code_context>
+        this.own = { id, verification, provider };
+      }
+    }
+    this.changed(id, verification);
+  }
+
</code_context>
<issue_to_address>
**Older mutation overwrites newer state**

When separate component instances or tabs mutate the same service and responses arrive in a different order from the registry’s applied changes, `applied()` emits each mutation result as it arrives, with no ordering or version check. If two instances mutate the same service and the registry applies PUT then DELETE but the responses arrive in reverse order, an event-driven consumer can apply the old PUT result last and show the service as verified when it is not.

Reconcile state after mutation events or include and compare a server ordering/version value before applying results.
</issue_to_address>

### Comment 6
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="298-299" />
<code_context>
+      this.loadRequest += 1;
+      this.current = verification;
+      if (this.verification !== undefined) {
+        this.own = { id, verification, provider };
+      }
+    }
+    this.changed(id, verification);
</code_context>
<issue_to_address>
**Successful mutation result disappears**

When a verify or remove succeeds with `verification` undefined, then the provider is replaced for the same registry, `applied()` does not save the result in `own`, and `load()` clears `current` before refetching. A 404, failed, or stale refetch then hides the result of the successful mutation.

Save successful mutation results in `own` even when `verification` is undefined, so `load()` can reuse them after a provider change.
</issue_to_address>

### Comment 7
<location path="packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts" line_range="163" />
<code_context>
+
+  /** Whether a verify or remove of the service shown is running. */
+  private get busy(): boolean {
+    return this.pending.has(this.targetId);
+  }
+
</code_context>
<issue_to_address>
**Old registry request disables new actions**

When a request is pending while the provider switches to another registry with the same service ID, `pending` and `busy` use only the service ID, so the old registry’s request keeps Verify or Remove disabled for the new registry until it settles. A hung request leaves the new registry’s actions disabled indefinitely.

Key pending work by both registry and service ID, and have `busy` check the current registry’s key.

Also at `packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts:164`, `packages/ecc-client-elixir-cloud-registry/src/components/service-verification/service-verification.ts:277-280`.
</issue_to_address>

### Comment 8
<location path="apps/documentation/pages/docs/cloud-registry/components/service-verification.mdx" line_range="120" />
<code_context>
+After a verify or remove, the component shows the result for that service until the app sets `verification` again, also if the provider is replaced meanwhile by one for the same registry (the same base URL, e.g. with a new token); update your verifications from `ecc-service-verification-changed`, as above. Pass a stable value (e.g. the object from the map, not one built on each render): every new value counts as set again.
+
+<Callout type='info'>
+  The services list of the GA4GH Service Registry package (`ecc-client-ga4gh-service-registry-services`) doesn't show verifications itself; place the component in a row's `actions-<id>` slot or in your own list.
+</Callout>
+
</code_context>
<issue_to_address>
**Badge missing from list**

The issue asks for a verified badge in the services list, but this change adds only a standalone component and says the list does not show verifications itself. Apps must wire the component into a row manually, so the list requirement remains partly met.
</issue_to_address>